第一週（Day 4）講過，我的系統其實是兩套：桌面端 AI 負責深度互動、NAS 端 Agent 負責 24/7 自動化。

用 Day 1 的說法，這兩套的定位是 🧠 大腦 與 💾 持久化系統——為什麼這樣拆，Day 7 用計價模式推導過了，今天不重複。今天講拆開之後的代價：兩套系統各跑各的，記憶就分裂了。桌面端今天跟我決定的事，NAS 端的自動推播渾然不知，兩個 AI 就會各說各話。

怎麼讓它們看到同一份事實、又不互相打架？這是純粹的記憶協作問題，Day 4 沒講，今天補上。

先交代這個方向的出處，因為它也不是我憑空想的。種子來自「蝦說 AI」的一集節目——〈兩個小金的溝通實驗｜Claude × GPT 能自己說話嗎？〉：讓兩個掛著同一個「小金」的 AI 互相對話。我聽完記住的是另一件事：**人格與記憶一旦外化成資料，就搬得動——同一份，這個系統能用，那個系統也能用。**那句話在我腦裡放了很久，後面這整套設計，都是從這顆種子長出來的。

先講一個我花了很久才想清楚的區別

在往下之前，得先把一件事講白，否則整篇會被誤讀：

它們共用的是檔案系統，不是記憶。

這兩件事的差別比字面上大得多。

同一份 MEMORY.md，NAS 端的 Agent 每次醒來會把它讀進 context——那是它的人格與記憶，構成它「是誰」的一部分。桌面端的 AI 讀同一個檔時，那只是一份資料，跟讀任何一份文件沒有兩樣——看完就算，對話一結束就沒了。

我可以請桌面端的 AI 去翻 NAS 端的長期記憶、翻它昨天做的夢、翻它三個月前的日誌——但那是一次查閱，不是繼承。它不會因此變成 Clawrion，也不會記得 Clawrion 上週跟我說過什麼。

反過來更明顯：桌面端這幾個月累積的工作記憶（我的偏好、踩過的坑、哪些做法被否決過），NAS 端的 Agent 從來沒看過，因為那些根本不在同步資料夾裡。而兩邊的短期對話記憶更是完全隔離——Agent 的 session 檔活在容器內部，不經同步，桌面端連檔案都碰不到。

所以精確的說法是：

理解這一點，下面三層機制的設計理由才會成立：既然共享的只是「寫下來的事實」，那所有協作設計的重點就變成——怎麼確保該寫下來的真的被寫下來，而且對方知道它是新的。

第一層：共享單一真相 + 雙向同步

單一真相來源：我建一份 SHARED_MEMORY.md，凡是跨系統要共知的——投資決策、系統狀態、待辦——只寫這一份，不在各自的私有記憶各記一份，從源頭避免不一致。

注意這裡的關鍵動作是「把口頭的東西落成檔案」。桌面端跟我討論完一個決定，如果沒有人把結論寫進這份檔，那個決定對 NAS 端來說等於沒發生過。這聽起來很基本，但它是這套協作最常失守的地方——聊得很盡興，然後沒有人負責落地。

雙向同步：這份檔透過 Syncthing 在本機 ↔ NAS 之間自動雙向同步。桌面端寫完，幾十秒內 NAS 端就讀得到。Syncthing 是點對點、不經第三方雲，跟「資料留在家」的原則一致。

兩套系統雖各跑各的，卻共讀同一本攤在桌上的筆記本。

第二層：衝突治理，但別過度工程

「兩邊都能寫同一份檔」聽起來危險——同時寫、互相覆蓋怎麼辦？這是分散式系統的經典難題，但我的處理刻意務實：

• 分段負責：約定誰主要維護哪些段落（系統狀態歸 NAS 端、互動決策歸桌面端），降低同時改同一段的機率。
• 時間戳註記：每次重要更新標上時間與來源，分歧時有依據判斷哪份較新。
• 寫入來源要留名：因為兩邊看到的是同一份檔，光看內容分不出是誰寫的。標上來源之後，我才能在讀到一段奇怪的記錄時判斷「這是自動化寫的還是討論時寫的」——這在追錯時比時間戳更有用。

這套約定不是沒被考驗過：半年來真的撞出過幾次 conflict 副本檔——兩端幾乎同時改同一份檔，同步工具把「輸的那份」留成副本，靠時間戳和來源留名判斷保留哪邊。副本機制保證輸的內容不會無聲消失，約定則讓裁決有依據——兩者都在，衝突就只是小事。

對個人規模，這套「約定 + 時間戳」就夠了，不需要搬出 CRDT 或分散式鎖。知道什麼時候不需要過度工程，也是一種設計能力。

第三層：重要的事走「交接」，不只靠同步

同步解決的是「兩邊看到同一份資料」，但它有盲點：它不知道哪些是「新的、需要對方處理」的。

這時候我用一套像醫院交班的機制——日班護理師下班前寫交接單，夜班照著看就知道要注意什麼：

• 日班寫：桌面端把當天的決策摘要 + 明確待辦，寫進 cowork_handoff/ 的日期檔。
• 夜班收：NAS 端 dreaming 啟動時掃描交接目錄，把新交接消化進當天記憶，處理完標記已消化避免重複。

為什麼用檔案、不用 message queue？因為對個人系統，檔案更簡單（少一個會壞的服務）、更可靠（同步已保證送達，不會像 queue 訊息被消費掉就沒）、更可讀（隨時翻歷史交接）、而且天生非同步（日班寫時夜班不用在線）。這是 multi-agent 協作的檔案系統解法。

交接單真正的價值，是一次烏龍教我的

這個機制平常感覺不到重要——直到最近它救了一次場，而且救的是我自己造成的混亂。

那天我請大腦那側把系統裡十幾個多餘的排程清掉。這是刻意的決定：退役的舊任務、已經觸發過的一次性提醒，留著只是雜訊。清完之後，當天的交接單照規矩寫了。

隔沒多久，另一個對話裡的 AI 助手在巡檢時發現「排程怎麼少了一批」，判斷是故障——把其中幾個還原了回去。

它沒有亂來。它看得到的所有證據——系統狀態、執行紀錄——都只說得出「這些東西以前在、現在不在」。**log 記得住「發生了什麼」，記不住「為什麼」；刻意的移除和意外的遺失，在系統狀態裡長得一模一樣。**全系統唯一記得「為什麼」的地方，就是那張交接單。後來也是靠翻它，才確認那批排程是我自己要刪的，把誤還原的再清掉一次。

所以現在我對交接單的理解升了一級：它不只是「讓對方知道有新的事要處理」，它是整套系統裡唯一的意圖紀錄。狀態誰都看得到，意圖只有寫下來才存在——這跟前面說的「有沒有人負責把結論寫下來」是同一件事，只是這次，是用一個烏龍學會的。

小結

兩個 AI 不分裂，靠一個認知加三層協作：

• 認知：它們共用檔案系統，不共用記憶。能同步的是寫下來的事實，不能同步的是當下的脈絡。
• 共享單一真相 + 雙向同步：SHARED_MEMORY.md + Syncthing，兩邊共讀一份
• 衝突治理：分段負責 + 時間戳 + 來源留名，務實不過度工程
• 非同步交接：像醫院交班，日班寫 handoff、夜班 dreaming 消化——用檔案取代 message queue
• 交接檔是唯一的意圖紀錄：log 記得「發生什麼」，記不得「為什麼」——一次誤還原的學費

如果只帶走一句：跨 AI 協作的瓶頸不在頻寬，在「有沒有人負責把結論寫下來」。

明天把鏡頭拉遠一格：兩個 AI 一起讀寫了半年之後，這個工作區長到了兩千多個 Markdown。記憶治理講了一週，我順手給治理系統自己做了個體檢——它也胖了。而且比胖更麻煩的是：它開始自相矛盾。

🔑 這篇的關鍵字
共用檔案系統 ≠ 共用記憶（能同步的是寫下來的事實，不是當下脈絡）· 單一真相來源（SSOT）· Syncthing 點對點雙向同步 · 衝突治理三招：分段負責 / 時間戳 / 寫入來源留名 · 非同步交接（handoff 檔案取代 message queue：更簡單、送達有保證、可讀歷史、天生非同步）· 交接檔＝意圖紀錄（狀態看得到，意圖要寫下來才存在；刻意移除與意外遺失在 log 裡長一樣）

我是一名金融業資訊工程師，這是我半年來在家自架 AI Agent 系統的實錄。